到目前為止,你的測試都是「想到才跑」。這一篇之後,它們會變成 24 小時值班的守衛:程式一有改動,自動全員出動。

前面二十幾篇在練功,這一篇開始上工。門檻比你想的低——手上的 TodoMVC 練習專案、一個免費的 GitHub 帳號,加上 Claude Code,一個下午就能完成。全程不需要你自己寫設定檔。

這篇會帶你做到三件事:讓 CI 跑起來、學會處理紅燈、把成果講給主管聽。

一、CI 是什麼

一句話:團隊的程式碼倉庫接了一個機器人,每當有人提交程式,它自動開一台乾淨的機器、安裝環境、跑完所有測試、把結果通知大家。

圖 1:從提交程式到自動把關的完整流程

關鍵在「自動」兩個字。把關不再依賴有人記得跑測試,而是想繞都繞不過去。你做手動測試多年最深的無力感之一——「改了東西沒人知會測試」——在這裡有了結構性的解法。

先講清楚 CI 不會做的事:它不會幫你寫測試,也不會讓寫得爛的測試變好。它只做一件事,把已經存在的測試,每次都跑。所以前面二十四篇的功夫,決定了這道防線值不值錢。

二、先看懂五段骨架,再談要用哪個平台

很多人第一時間卡在這裡:「我們公司用的是 Jenkins,文章教 GitHub Actions,看了也用不上。」這個顧慮可以先放下。

所有 CI Server 的設定檔,講的都是同樣五件事:

圖 2:任何 CI Server 都是這五段,換平台只是換寫法

把五段跟四個常見平台放在一起看,會更有感覺:

實務建議:先在 GitHub 上把整套跑通一次(免費、開一個新專案只要五分鐘),把「五段」的感覺建立起來,再回公司的平台複製同一套骨架。搬家時你要問的只有一句話:「同樣這五段,在 Jenkins 上怎麼寫?」

三、動手做:三十分鐘把 TodoMVC 送上 CI

全程需要準備的東西:一個 GitHub 免費帳號、本機可以正常執行的 TodoMVC 練習專案、Claude Code。

Step 0|先確認本機是綠的
在自己電腦上跑一次 npx playwright test,全部通過再往下走。本機是紅的就推上 CI,只會讓你分不清問題出在哪一邊。

Step 1|讓 Claude Code 幫專案做上 CI 前的體檢
▍給 Claude Code 的提示詞

我要把這個 Playwright 專案放上 CI。請先幫我檢查會在 CI 上出問題的地方:
 
1. 有沒有寫死的本機路徑、寫死的網址、寫死的帳號密碼
2. 有沒有依賴「我電腦上本來就有的資料」才能跑的測試
3. 有沒有用固定秒數等待(waitForTimeout)
4. package.json 的相依套件與 scripts 是否完整,別人 clone 下來能不能直接跑

把問題列成清單,標出檔案跟行數,先不要動手改,讓我確認。

為什麼先體檢:在 CI 上除錯比在本機慢十倍,每改一次都要等它重跑一輪。先在本機把明顯的地雷清掉,可以省下一整個下午。

Step 2|請 Claude Code 產生設定檔
▍給 Claude Code 的提示詞

幫這個專案設定 GitHub Actions,要求如下:
 
- 每次 push 和 pull request 都自動執行全部 Playwright 測試
- 使用 Node 20,並安裝 Playwright 需要的瀏覽器
- 測試帳號密碼用 GitHub Secrets 管理,不要出現在設定檔裡
- 不論成功或失敗,都保留 HTML 報告與失敗時的 trace,讓我可以下載
- 整包測試超過 15 分鐘就中止
 
設定完成後,用白話逐段解釋這個檔案在做什麼,並告訴我 Secrets 要去哪裡設定。

最後那句「用白話逐段解釋」不要省略。你不需要會寫 YAML,但必須看得懂它在做什麼——哪天要調整、要搬家、要跟開發解釋,靠的都是這個。

Step 3|把密碼放進 Secrets
第 12 篇說過密碼不進程式碼,CI 上的正解是平台提供的 Secrets 機制。以 GitHub 為例,路徑是:

Repository → Settings → Secrets and variables → Actions → New repository secret

設定一次,執行時自動注入,任何人在執行紀錄裡看到的都是 ***。順手再做一件事:
▍給 Claude Code 的提示詞

掃描整個專案(包含測試檔、設定檔、README、git 歷史紀錄),
找出任何看起來像帳號、密碼、API key、token 的字串,列出位置。

Step 4|推上去,看第一次自動執行
▍給 Claude Code 的提示詞

幫我把這個專案推上 GitHub。我還沒有建 repository,
請一步一步告訴我要做什麼,指令直接給我可以貼上的版本。

推完之後,打開 GitHub 上的 Actions 頁籤,你會看到一顆正在轉的黃點。這是你的測試第一次在別人的機器上跑。

Step 5|故意弄壞它,走完一次紅燈流程
跑出綠燈只是確認一切正常,真正要練的是紅燈來的時候怎麼辦。挑一個測試,把預期結果改成錯的(例如把預期的待辦數量從 2 改成 3),推上去。

然後完整走一次:

收到通知 → 打開 CI 執行紀錄 → 找到失敗的那一條
        → 下載 artifacts 裡的報告與 trace
        → 用第 10 篇的方法看它停在哪一步
        → 改回來 → 看它變綠

這一輪走完,你就具備了在 CI 上除錯的完整能力。之後遇到的每一顆紅燈,流程都是這個。

附:一份可以直接用的 GitHub Actions 設定檔
放在專案的 .github/workflows/playwright.yml。右邊的註解對應圖 2 的五段骨架:

name: Playwright Tests
 
on:                                    # ① 什麼時候跑
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]
 
jobs:
  test:
    timeout-minutes: 15
    runs-on: ubuntu-latest             # ② 在哪裡跑
 
    steps:
      - uses: actions/checkout@v4
 
      - uses: actions/setup-node@v4    # ③ 準備什麼
        with:
          node-version: 20
 
      - name: 安裝相依套件
        run: npm ci
 
      - name: 安裝瀏覽器
        run: npx playwright install --with-deps
 
      - name: 執行測試                  # ④ 跑什麼
        run: npx playwright test
        env:
          TEST_USER: ${{ secrets.TEST_USER }}
          TEST_PASSWORD: ${{ secrets.TEST_PASSWORD }}
 
      - name: 保留報告與 trace           # ⑤ 留下什麼
        uses: actions/upload-artifact@v4
        if: always()
        with:
          name: playwright-report
          path: playwright-report/
          retention-days: 7

特別注意 if: always() 這一行。少了它,測試失敗時報告不會被保留,而失敗那一次的報告,正是你最需要的。

四、換成公司在用的 CI Server

骨架相同,所以搬家的提示詞也長得一樣:
▍給 Claude Code 的提示詞(換平台通用)

我有一份可以正常運作的 GitHub Actions 設定檔(附在下面),
請幫我改寫成 GitLab CI 的 .gitlab-ci.yml,功能要完全對應:
一樣的觸發時機、一樣的 Node 版本、一樣用 Secrets 管理帳密、一樣保留報告與 trace。
 
改寫完成後,列一張對照表告訴我哪一段對應到原本的哪一段,
以及 GitLab 上的密碼要去哪裡設定。
 
[貼上原本的 workflow 檔]

把「GitLab CI 的 .gitlab-ci.yml」換成 Jenkinsfile、azure-pipelines.yml、bitbucket-pipelines.yml,提示詞完全通用。

幾個搬家時最常踩到的差異,先知道會省很多時間:

• 瀏覽器怎麼來:雲端平台習慣用 npx playwright install --with-deps 現裝。公司的 Jenkins 機器如果沒有對外網路權限,通常改用 Playwright 官方的 Docker image。
• 報告怎麼看:各平台「產物」的名稱不同(artifacts、archiveArtifacts、Publish Build Artifacts),作用都是把檔案留下來讓你下載。
• 誰來跑:雲端平台有現成的機器可以用;Jenkins 通常要指定 agent 或 node,這一段要找公司管 Jenkins 的人問清楚,問一次就好。

五、第一週的經典場面:本機綠、CI 紅

這件事大概率會遇到。別慌,兇手名單你都認識:

圖 3:本機過、CI 不過的三大兇手與對應解法

除錯的時候,把資訊整包餵給 Claude Code,比自己盯著 log 看快很多:
▍給 Claude Code 的提示詞

這條測試在我電腦上會過,在 CI 上失敗。以下是 CI 的錯誤訊息與測試程式碼。
 
請先判斷這比較像環境差異、時序問題,還是資料互相干擾,說明你的理由,
再給我修改建議。修改後的測試在本機跟 CI 上都要能穩定通過。
 
[貼上 CI 的錯誤訊息]
[貼上測試程式碼]

「先判斷比較像哪一類、說明理由」這一句很重要。少了它,AI 傾向直接動手改,而最常見的改法是把等待時間加長——問題被蓋住了,但沒有解決,過兩週它會用更難查的形式回來。

可維護性篇前面幾篇的功夫,全是為了這一刻。測試在自己電腦跑得過只是及格,在一台陌生的機器上穩定跑得過,才算畢業。

六、紅燈進來,你的第一個動作

圖 4:一顆紅燈進來的三種可能與對應處理

你在這裡有一個天然的角色:紅燈的第一線判讀者。一顆紅燈進來,是產品 bug、測試自己寫錯、還是環境在抖,你用第 10 篇的功夫給出初判,決定該叫醒誰。這個角色做得好,你就是團隊裡紅燈公信力的守護者。

三個實務提醒:
• 分類要留紀錄。開一份很簡單的表就好(日期、紅燈原因、歸到哪一類、怎麼處理),兩個月後你會看出某一類特別多,那就是下一個該修的地方。
• 「環境在抖」不能一直當免死金牌。同一條測試因為抖動被重跑三次,它就升格成待辦事項,回去看第 23 篇的處理方式。
• 初判不需要百分之百準確。你的價值在於「五分鐘內給出方向」,而不是自己把每個問題都查到底。

七、技術半天搞定,文化決定生死

CI 的技術部分,一個下午就能跑起來。真正的成敗在團隊怎麼對待紅燈。

圖 5:紅燈是命令還是背景音,決定 CI 的生死

決定走向的,是前面幾篇的累積:測試穩(第 23 篇)、可讀(第 21、24 篇)、獨立(第 22 篇),紅燈才有公信力,團隊才願意為它停下來。這件事喊口號沒有用,靠的是紅燈每一次都「值得停」,慢慢掙來的信任。

你能做的具體事情有兩件:讓紅燈盡量準確(前面幾篇的功夫),以及每一次紅燈都在第一時間給出判斷(上一節的角色)。

八、跟主管交代成果:三件套

CI 跑起來之後,很快會面對一個現實的問題:「所以自動化這陣子的產出是什麼?」這題答得好不好,決定資源會不會繼續給。

圖 6:向上展示成果的三件套

準備三樣東西,每次都拿得出手:

• 一張報表:CI 的執行紀錄與通過率趨勢,證明防線天天在值班。截圖就行,不用做簡報。
• 一個案例:某次改版被測試擋下來的真實 bug,講清楚「如果沒有這道防線,它會流到哪裡」。一個具體案例勝過十頁統計。
• 一筆帳:回歸測試從手動點一輪的工時,到現在自動跑完的時間。省下的人力去了哪裡也要講清楚——去做探索測試和新功能驗證。

頻率上,雙週或每月一次、五分鐘講完就好。目的是讓決策者持續看見:這條生產線每天都在運轉。
一個實作提醒:「一筆帳」的基準值現在不記,以後就沒得比。今天就把手動回歸一輪的工時寫下來,一行字也好。